GDPR Support to History Screens

As per GDPR (General Data Protection Regulation), if History Screens has any sensitive data or PII field, then it supports the following GDPR features.

• Masking
• GDPR Purging

Masking Support to History Screens

The history screens supports masking in OIPA. When the PII fields are written to the history table, OIPA supports masking functionality to these PII fields. The users can configure masking for all PII Data irrespective of business rule configuration.

The following history screens supports masking:

• Client History
• Comments History
• Suspense History
• Group Customer History

Since History page does not have a screen rule, the masked fields are not available in security pages. Palette is enhanced to read the appropriate screen rule for each history page.

For example: On Client History page, palette reads Client Screen rule and retrieve the masked fields. Similarly, on SuspenseHistory page, palette will read Suspense.

Then security controls are applied for these masked fields on history page itself. In OIPA, History pages read the appropriate configuration and security levels for masked fields.

OIPA directly read the History screens (Agreement Role History, Address History and Comments History) that are missing in the palette from the respective screen rules.

GDPR Purging Support to History Screens

OIPA maintains Write/ Edit logs for all the history screens with sensitive data or PII fields. These history screens can be linked to GDPR purging. You can configure the automatic log purging in defined time or date.

If the following History screens has any PII data, then it can be linked to GDPR purging:

• Agreement Role History
• Requirement History
• Segment Role History
• Policy Role History
• Role History
• Address History
• Intake Profile History
• Agreement History
• Client History
• Comments History
• Suspense History
• Group Customer History

These are the values in AsCode for History Types:

History Type	Code
ClientHistory	01
RoleHistory	02
SuspenseHistory	03
RequirementHistory	04
AddressHistory	05
AllocationHistory	06
FundHistory	07
ChildFundHistory	08
SegmentRoleHistory	10
CommentsHistory	11
ProgramHistory	16
ClientAltIdHistory	18
GroupCustomerHistory	19
GroupCustAddressHistory	20
WorkflowHistory	23
AgreementHistory	25
IntakeProfileHistory	26

These are the values in AsCode for History Operations:

History Operations	Code
Add	01
Delete	02
Update	03
Convert	04
Details	05
System Add	06

Introduction to History Captured for Entities Created/Updated via Service APIs

Oracle Insurance Policy Administration introduces a significant enhancement to its audit framework with the addition of GDPR-aligned audit logging for API-driven updates. Historically, history entries were captured only for changes performed manually through the OIPA user interface. With this enhancement, any data modifications initiated through service APIs—whether they involve creating, updating, or modifying client, role, requirement, phone, address, or related entities—are now automatically recorded in the system’s history records.

To improve transparency and traceability, each history entry now includes a dedicated UpdateSource indicator, enabling users and auditors to clearly distinguish between manual (M) and API-based (A) modifications. This ensures consistent visibility into the origin of every change and supports more robust oversight for operational, integration, and compliance teams.

In addition, OIPA now logs failed API attempts in a newly introduced AsRestServiceErrors table. This mechanism captures essential metadata—while avoiding storage of invalid personal data—thus supporting GDPR principles of accuracy, accountability, and data minimization.

Together, these enhancements deliver a comprehensive, unified, and compliant history of entities, strengthening visibility across all entity updates and ensuring that API integrations adhere to the same regulatory and operational standards as manual system interactions.

APIs for Which History is Captured

• Client APIs

  • POST /clients

  • PUT /clients/{id}

  • PATCH /clients/{id}

• Client Phone APIs

  • POST /clients/{Id}/phones

  • PUT /clients/{Id}/phones/{Id}

  • PATCH /clients/{Id}/phones/{Id}

• Client Address APIs

  • POST /clients/{Id}/addresses

  • PUT /clients/{Id}/addresses/{Id}

  • PATCH /clients/{Id}/addresses/{Id}

• Group Customer APIs

  • POST /groupCustomers

  • PUT /groupCustomers/{id}

  • PATCH /groupCustomers/{id}

• Policy Role APIs

  • POST /policy/{id}/roles

  • PUT /policy/{id}/roles/{id}

  • PATCH /policy/{id}/roles/{id}

• Policy Requirement APIs

  • POST /policy/{id}/requirements

  • PUT /policy/{id}/requirements/{id}

  • PATCH /policy/{id}/requirements/{id}

• Segment Role APIs

  • POST /segments/{id}/roles

  • PUT /segments/{id}/roles/{id}

  • PATCH /segments/{id}/roles/{id}

• Suspense APIs

  • POST /suspenses

  • PUT /suspenses/{suspenseId}

  • PATCH /suspenses/{suspenseId}

• Workflow Task APIs

  • POST /workflowTasks

  • PUT /workflowTasks/{Id}

  • PATCH /workflowTasks/{Id}